A METHOD FOR MANAGING PUBLIC KEY 



BACKGROUND OF THE INVENTION 

The present invention relates to a method for 
managing a public key, and more particularly to the 
method for managing a public key which is appropriate 
to a public key encryption system used for keeping 
security of a network. 

As a method of realizing security in 
communications through the internet, for example, an 
IPSEC (IP SECurity) may be referred which is a security 
protocol for IP (Internet Protocol) layers. A 
representative one of the publications on the IPSEC is 
[REC1825] "Security Architecture for the Internet 
Protocol" written by R. Atkinson and issued by IETF 
(Internet Engineering Task Force). 

The key management protocol accompanied with 
the IPSEC uses the public key encryption system. As 
the prior art on the key management protocol, for 
example, the technology called SKIP has been known 
which is described in "Simple Key-Management For 
Internet Protocol" written by Ashar Aziz, Tom Markson, 
Hemma Praf ullchandra and issued by IETF. Hereafter, 
the key management protocol will be described. 

It is assumed that two hosts A and B are 
provided for executing security communications within a 
network and encryption communications through the use 
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of the common key encryption system based on the IPSEC, 
in which the host A knows the public key of the host B, 
while the host B knows the public key of the host A* 

In doing communications, the host A operates 
5 to combine its own secret key with the other public key 
for creating a key K(A) for encrypting the common key, 
while the host B operates in the same manner for 
creating a key K(B) for encrypting the common key. For 
example, when the host A transmits data to the host B, 

10 the host A operates to create the common key T and 

encrypt the data with the common key T and the common 
key T with the key K(A) • The host A operates to insert 
a new header containing information on the encrypted 
common key T after the IP header. The host B on the 

15 receiving side operates to decrypt the encrypted common 
key T in the packets with its own secret key and 
decrypt the data of the encrypted packets with the 
decrypted common key T. In the security communication 
between the hosts A and B, the common key for 

20 encrypting the data is periodically updated. 

The conventional key management protocol 
accompanied with the IPSEC requires the two hosts for 
doing the security communication with each other to 
know the other's public key before starting the 

25 communication. 

The aforementioned conventional method does 
not have a method for automatically and safely 
exchanging the public key between the two hosts that 
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try to do the security communication before starting 
the communication. It means that for exchanging the 
public key one public key has to be given to the other 
host by hands, which disadvantageously makes the 
5 management of the public key more complicated. 

Further, if the network is configured in larger scale, 
this prior art has a disadvantage that it puts a 
greater burden on a manager of the network. 

As another disadvantage, if the public key 
10 unaccompanied with authentication on the network is 
distributed, the foregoing prior art cannot prevent a 
malignant host from being feigned to be a proper target 
host of the security communication. 



SUMMARY OF THE INVENTION 

15 It is an object of the present invention to 

provide a method for managing a public key which is 
arranged to overcome the foregoing disadvantages the 
prior art involves and allow the two hosts that try to 
do the security communication to automatically and 

20 safely exchange the public keys with each other before 
starting the communication. 

According to an aspect of the invention, the 
object may be achieved as follows. A public key 
management system is provided in which the system 

2 5 includes a hierarchical network with a domain name at 
each layer, a DNS server provided at each layer for 
managing the correspondence between the domain name and 
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the address, and a host held in the network itself, the 
DNS server serving to distribute a public key of 
another host to the hosts belonging to the network. 
The DNS server includes means for managing the public 
5 key and a database for storing the public key of the 
host belonging to the network and its domain name in a 
corresponding manner- When an inquiry of the public 
key of the second host through the information of the 
domain name is given to the network by the first host, 

10 the means for managing a public key is served to refer 
to the database so that the information about the 
public key of the second host corresponding to the 
domain name is given to the first host. 

Further, the foregoing object may be achieved 

15 as follows. When the DNS server receives an inquiry of 
the public key of the second host from the first host, 
if no entry corresponding to the domain name of inquiry 
is found in the database included in the DNS server, 
the solution of the public key is recursively entrusted 

2 0 to another DNS server provided with the corresponding 
means for managing a public key and a database along 
each layer of the domain name. 

Further, the foregoing object may be achieved 
as follows. The host provides means for inquiring the 

25 public key of another host of the DNS server. When the 
security communication is started, the inquiry about 
the corresponding public key to the domain name of the 
target host is given to the means for inquiring the 
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public key provided in the DNS server. 

The object of the invention may be achieved 
by providing the following means except the 
configuration having the foregoing means. 
5 That is, if the configuration of the network 

is changed, the foregoing object is achieved by some 
DNS servers relevant to the change of the configuration 
serving to update the database for storing the public 
key of the host and the domain name in a corresponding 

10 manner and the other DNS servers serving not to update 
the database. 

Further, the foregoing object may be achieved 
by providing means for processing an electric signature 
in the DNS server having the means for managing a 

15 public key and the database and in means for inquiring 
the public key, adding the electronic signature to the 
packet outputted for inquiring the public key and 
answering the inquiry, making sure of the electronic 
signature of the inputted packet with the electronic 

20 signature, and discarding the interpolated packets, for 
preventing the content of the packets from being 
interpolated . 

Moreover, the foregoing object may be 
achieved by the DNS server having the means for 

25 managing a public key and the database for inquiring 
the public key and answering to it and the host having 
means for inquiring the public key, both of the DNS 
server and the host using the same format for the 
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packets as the conventional DNS packets. 

The foregoing object may be achieved by, 
before answering the information of the public key 
containing the information about the domain name of the 
5 DNS server trusted by the host contained in the packets 
for inquiring the public key transmitted by the host to 
the DNS server, prompting the means for managing a 
public key of the DNS server to request an electronic 
signature of the DNS server trusted by the host 

10 indicated in the packets for inquiring the public key, 
prompting the means for managing a public key of the 
DNS server having received the request of the 
electronic signature to add an electronic signature to 
the packets for answering the public key, prompting the 

15 means for processing the electronic signature of the 
host to determine if the information of the public key 
contained in the packet for answering the public key is 
trusted on the electronic signature, thereby preventing 
a malignant host from being feigned to correspond its 

2 0 own public key and address with the domain name of 
inquiry contained in the packet for inquiring the 
public key. 

The foregoing object may be achieved by, when 
the DNS server having received the request for the 
2 5 electronic signature is different from the DNS server 
trusted by the host indicated in the packet for 
inquiring the public key, prompting the means for 
managing a public key of the DNS server to request the 
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DNS server on the upper layer of the electronic 
signature for the packet for answering the public key 
along the hierarchical structure of the domain name, 
and prompting the DNS server trusted by the host 
5 indicated in the packet for inquiring the public key to 
add the electronic signature to the packet for 
answering the public key. 

The foregoing object may be achieved by 
prompting the means for inquiring the public key 

10 provided in the host to select the trusted DNS server 
according to the domain name of inquiry and thereby 
decreasing the number of the DNS servers for adding an 
electronic signature to the packet for answering the 
public key containing the information about the domain 

15 name of the DNS server, thereby making the acquisition 
of the public key more efficient. 

The foregoing object may be achieved by 
caching the information of a public key, an electronic 
signature and a domain name of the server to which the 

20 electronic signature has been added, contained in the 
packets for answering the public key with the 
electronic signature in means for managing a public key 
of the DNS server having received the response of the 
public key with the electronic signature, thereby 

25 preventing a wasteful burden from being put on the 
network and the server and making the acquisition of 
the public key more efficient. 

As mentioned above, the DNS served as means 




- 8 - 

for solving the correspondence between the domain name 
and the address of the network operates to expand the 
function of the DNS server served as realizing the DNS 
and provides means for solving the correspondence 
5 between the domain name and the public key. The method 
for realizing the DNS will be described in [REF1035] 
"Domain Names - Implementation and Specifications" 
written by P. Mockapetris and issued by IETF. 

According to the invention, the function- 

10 expanded DNS server having the means for managing a 

public key and a database for storing a public key and 
a domain name of the host belonging to the network in a 
corresponding manner operates to answer the public key 
corresponding to the domain name of inquiry to the host 

15 by prompting the means for managing the public key to 
respond the database when the inquiry of the public key 
is received from the host through the information of 
the domain name. When the two hosts on the network 
start the security communication, one host operates to 

20 automatically acquire the corresponding public key to 
the domain name of the target host, thereby making the 
management of the public key in the network easier. 

According to the invention, the name of the 
DNS server trusted by the host is contained in the 

25 packet for inquiring the public key and the electronic 
signature is added to the packet for answering the 
public key by the DNS server trusted by this host. 
Hence, the host enables to determines if the public key 
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contained in the packets for answering the public key 
may be trusted, thereby preventing a malignant host 
from being feigned to correspond its own public key and 
address with the domain name of inquiry, that is, being 
5 passed off as the target host for the security 

communication. The foregoing function-expanded DNS 
server is served to add the electronic signature to all 
the packets to be transferred for acquiring the public 
key, thereby preventing the content of the packets from 
10 being interpolated. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram showing a 
configuration of a KMS (Key Management Server) 
according to an embodiment of the present invention; 
15 Fig. 2 is a block diagram showing a 

configuration of a host having a function as a DNS 
client in the foregoing embodiment; 

Fig. 3 is a table showing a composition of a 
table for describing correspondence between a public 
20 key and a domain name in the foregoing embodiment; 

Fig. 4 is a flowchart for describing a 
routine for answering a public key when a DNS server 
receives an inquiry of the public key; 

Fig. 5 is a flowchart for describing a 
25 routine for adding an electronic signature to the 
packets for answering the public key when the DNS 
server receives the request of the electronic 



signature; 

Fig. 6 is a flowchart for describing a 
routine in which the host having a function of the DNS 
client acquires the public key of the target host; 

Fig. 7 is a block diagram showing the 
application of the invention to the network having a 
hierarchical structure of a domain name; 

Fig. 8 is a view for describing types of 
packets to be transferred between the host and the KMS 
and between the KMS and the KMS and electronic 
signatures added thereto in the routine in which the 
host acquires the public key of the target host; 

Fig. 9 is a view for describing the 
composition of the format of the DNS packets; and 

Fig. 10 is a view for describing the 
composition of the format of a resource record 
contained in the DNS packets. 

DESCRIPTION OF THE EMBODIMENTS 

Hereafter, the description will be oriented 
to a system for managing a public key according to an 
embodiment of the present invention with reference to 
the appended drawings . 

'^^^[ig. 1 is a block diagram showing a 
configuration oi^^a..KMS (Key Management Server) included 
in a system for managing^^a^ublic key according to an 
embodiment of the present inverrbiQn. Fig. 2 is a block 
diagram showing a configuration of a nbet having a 
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\ function as a DNS client. The KMS is a server having 
\ an expanded function of the DNS server. Likewise, the 
\host has a function as the function-expanded DNS 
c\ient. Fig. 3 shows the composition of the table for 
5 desy^ribing the correspondence between the public key 
and ^e domain name. Fig. 4 is a flowchart for 
descriqing the routine in which the DNS server answers 
the publ\c key when it receives an inquiry of the 
public key\ Fig. 5 is a flowchart for describing the 

10 routine in which the electronic signature is added to 
the packet foAanswering the public key when the DNS 
server receives Vn inquiry of the electronic signature. 
Fig. 6 is a flowcnsart for describing the routine in 
which the host having a function of the DNS client 

15 acquires the open keyNof the target host. Fig. 7 is a 
block diagram showing tK^ application of the invention 
to the network having theNshierarchical structure of the 
domain name. Fig. 8 is an (explanatory view showing the 
types of packets to be transferred between the host and 

20 the KMS and between the KMS ank the KMS and the 

electronic signatures added therVto. Fig. 9 is an 
explanatory view showing the compo^^ition of the format 
of the DNS packet. Fig. 10 is an explanatory view 
showing the composition of the format ^f a resource 

25 record contained in the DNS packet. InNFigs . 1, 2, 7 
and 8, a numeral 10 denotes a KMS. NumeraJ.s 11 and 21 
denote network control units. Numerals 12 \nd 22 
denote IP processing units. Numerals 13 and \3 denote 
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[•CP/UDP processing units. A numeral 14 denotes an 
expanded DNS processing unit. A numeral 15 denotes a 
domasin name/IP address table. Numerals 16 and 25 
denote^ domain name/public key/electronic signature 
table, ^umerals 17 and 2 6 denote initial holding data. 
A numeral x4 denotes an expanded DNS client. A numeral 
27 denotes a\security communication processing unit. A 
numeral 101 denptes a network. Numerals 141 and 241 
denote DNS packetNs^eparating units. A numeral 142 
0 denotes a DNS processing unit. A numeral 143 denotes a 
public key inquiry /ansWering unit. A numeral 144 
denotes an electronic signature processing unit. A 
numeral 24 2 denotes a domaxo name resolver. A numeral 
243 denotes a public key inqiriry processor. A numeral 
5 244 denotes an electronic signature processing unit. 
Numerals 71 and 75 denote hosts A^nd B. Numerals 72 
to 7 4 and 7 6 denote KMS • s . 

At first, the configuration of the overall 
network system and the flow of the processing to which 
0 the present invention may be applied will be described 
with reference to Fig. 7. 

In the network system shown in Fig. 7, the 
network has a^Si^erarchical structure, each hierarchy 
layer of which is gi^^n a domain name. Each layer with 
its own domain has one KMS ^^MJerein, consider that the 
host A71 acquires the public key of-<^e host B75. In 
this case, the host A71 inquires the KMS5><7 2 ) located 
in the hierarchy of the same domain of the publ^ircL key 
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osE the host B75. At this time, merely by receiving the 
dat^ of the public key of the host B75, it is 
imposvsible to prevent a malignant host from being 
feigned, to be the host B7 5. Hence, the host A71 
5 requests\the electronic signature of the KMS to be 

trusted. l^e KMS trusted by the host A71 is made to be 
the KMSOO ( 7X^ . Further, the public key of the KMS 00 
(74) is known ivp the host A71 as well as the other 
hosts and is autl^enticated to all the hosts. 

10 When theVhost A71 requests the data on the 

public key of the h^t 375, if the KMSl (72) has the 
key on the public keyNpf the host B75 in response to 
this request, the KMS 00. (74) trusted by the host A71 
is requested to add the electronic signature to the 

15 data on the public key. OnVthe other hand, if the KMSl 
(72) does not have the data cm the public key of the 
host B75, the KMSl (72) inquirdte the upper KMSO (73). 
In this case, the inquiry to the Nipper KMS is 
recursively continued until the KMSSl (72) reaches the 

20 KMS having the data on the public keys, of the host B75. 
The KMS having the data on the public i^y of the host 
B75 serves to request the KMSOO (74) to add the 
electronic signature in response to the inquiry from 
the KMSl (72) . \ 

25 The KMSOO (74) requested to add the electronic 

signature operates to give back the data on the public 
key of the host B75 to the KMSl (72). The KMSl (720 
operates to give back the data on the public key of the 
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hd:^ B75 to the host A71. In this case, the host A71 
operalsas to determine if the data is to be trusted 
because it^originally knows the public key of the KMSOO 
(74). 

5 The fol^^oing series of processes make it 

possible for the hosbsA71 to safely acquire the open 
key of the host B75. Thfevuse of the public key 
therefore makes it possible tso do the security 
communication with the host B75, 

10 In turn, the description will be oriented to 

the composition of the format of the DNS packet and the 
composition of the format of the resource record 
contained in the DNS packet. 

As shown in Fig. 9, the DNS packet is made up 

15 of a DNS header 91, an inquiry portion 92, a reply 

portion 93, an authorization portion 94 representing a 
name of a name server with authorization, and an 
additional information portion 95 having plural 
resource records. As shown in Fig. 10, a TXT record, 

20 which corresponds to one of the resource records 

contained in the DNS packet, is made up of a name field 
101, a TYPE field 102, a CLASS field 103, a TTL field 
104 for indicating an interval of time when the 
resource record is cached without being discarded, a 

25 data length field 105, and a data field 106. 

The resource records may be identified by 
TYPE. In this embodiment, the public key inquiry 
information and the public key answer information are 
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put into the resource record with TYPE=16 called TXT 
record in the DNS resource records. In this 
embodiment, an identifier field 1061 is provided at the 
head of the data field 106 of the resource record to 
5 which the public key inquiry information and the public 
key answer information are to be put. This identifier 
field is served to distinguish the records, concretely, 
the public key inquiry /answer , the electronic signature 
request, or the normal TXT record. 

10 The TXT record is described in the 

aforementioned literature about the DNS. In addition, 
the resource record may include an A record (TYPE = 1) 
for indicating correspondence between an address and a 
domain name, and a MX record (TYPE = 15) for indicating 

15 a domain name of a main exchanger, and so forth in 
addition to the foregoing TXT record. 

In turn, the description will be oriented to 
the configuration of the KMS which corresponds to the 
server according to this embodiment of the invention 

20 with reference to Fig. 1. In Fig. 1, a real line 

connecting the blocks with each other indicates how the 
packets are transferred. A broken line indicates the 
reference to data. 

The KMS 10 is configured to have a network 

25 control unit 11, an IP processing unit 12, a TCP/UDP 

processing unit 13, an expanded DNS processing unit 14, 
a domain name/ IP address table 15, a domain name/public 
key/electronic signature table 16, and initial holding 
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data 17. The KMS 10 is connected to a network 101 
through the network control unit 11. The expanded DNS 
processing unit 14 is configured to have a DNS packet 
separating unit 141, a DNS processing unit 142, a 
5 public key inquiry/answer processing unit 143, and an 
electronic signature processing unit 144. 

As stated above, the network processing unit 
11 connects the KMS 10 with the IP network 101. The IP 
processing unit 12 is located upward of the network 

10 control unit 11 and operates to transfer the packets 
according to the IP (Internet Protocol). The TCP/UDP 
processing unit 13 is located upward of the IP 
processing unit 12 and operates to transfer the packets 
according to the TCP/UDP (Transmission Control 

15 Protocol/User Datagram Protocol). In particular, when 
a packet with a socket number allocated to the DNS is 
received, the TCP/UDP processing unit 13 operates to 
send the packet to the expanded DNS processing unit 14. 
Conversely, the expanded DNS processing unit 14 

20 operates to send the packet generated by itself to the 
TCP/UDP processing unit 13. 

The DNS packet separating unit 141 provided 
in the expanded DNS processing unit 14 operates to 
receive the DNS packet from the TCP/UDP processing unit 

25 13 and separate the DNS packet into any one of the DNS 
processing unit 142, the public key inquiry/answer 
processing unit 143, and the electronic signature 
processing unit 144 by checking the identifier 1061 
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shown in Fig. 10. The DNS processing unit 142 operates 
to receive the conventional DNS packet from the TCP/UDP 
processing unit 13 and retrieve the domain name/IP 
address table or add an entry to the table. The domain 
5 name/IP address table is a database for storing the 
domain name and the IP address in the corresponding 
manner. When the public key inquiry /answer processing 
143 receives the inquiry of the public key from another 
KMS from the TCP/UDP processing unit 13 in the format 
10 of the expanded DNS packet, the public key 

inquiry/answer processing unit 143 operates to retrieve 
the domain name/public key/electronic signature table 
16 for storing the domain name and the public key in 
the corresponding manner, for the purpose of acquiring 
15 the public key of the domain name of inquiry. 

The domain Name/Public Key/Electronic 
Signatu^^ Table 16, as shown in Fig. 3, contains a 
domain name\31, a public key 32, an electronic 
signature addeos^y the KMS trusted by the host, a KMS 
20 name 34 of the KMS\having added the signature, and a 
time stamp 35 for indrc^ating a time point of creating 
an entry. If an entry is\given to the table 16, the 
public key inquiry/answer prx>cessing unit 143 operates 
to issue a request for an electrsmic signature to 
25 another KMS according to the inquirV request or the 
electronic signature processing unit 14^ operates to 
add an electronic signature to the answer packets for 
the public key. If no entry is given to the xvable, the 
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mblic key inquiry/answer processing unit 143 operates 
to \xansmit the packets for inquiring the public key of 
the doih^n name of inquiry to another KMS through the 
TCP/UDP processing unit 13. The electronic signature 
processing uniK 144 operates to issue a request for an 
electronic signatu^se to another KMS according to the 
inquiry request or ada\an electronic signature to the 
answer packets of the pubric key when the unit 144 
receives the request for an erectronic signature from 
another KMS in the format of the expanded DNS packet 
from the TCP/UDP processing unit 13. 

Further, the KMS 10 holds the initial holding 
data 17. The initial holding data 17 is made up of a 
domain name/public key 171 of its own, a domain name 
172 of the upper KMS in the parentage of the DNS, and a 
domain name/public key 173 of the trusted KMS located 
downward in the parentage of the DNS. The KMS 10 
operates to reference the data when it goes to another 
KMS for inquiring the public key. 

In turn, the description will be oriented to 
the configuration of the host having a function of the 
expanded DNS client according to the invention with 
reference to Fig. 2. 

The host 2 0 is configured to have a network 
control unit 2 iT'-^^w.^lP processing unit 22, a TCP/UDP 
processing unit 23, an expattd^d DNS client 24, a domain 
name/public key/electronic signature^^^^^^le 25, initial 
holding data 26, and a security communicatioi 
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proc5fe^ing unit 2 7 and is connected to the IP network 
101 throi^5h the network control unit 11, The expanded 
DNS client 24N^ made up of a DNS packet separating 
unit 241, a domairNqame resolver 242, a public key 
5 inquiry processing unit'^43, and an electronic 
signature check unit 244, 

As stated before, like the KMS, the host 20 
includes the network control unit 21, the IP processing 
unit 22, and the TCP/UDP processing unit 23 and is 
10 connected to the IP network 201. when the TCP/UDP 

processing unit 23 receives the packet having a socket 
number allocated to the DNS, the unit 23 operates to 
transmit the packet to the expanded DNS client 24. 
Conversely, when the expanded DNS client 24 transmits 
15 the packet generated by itself, the client 24 operates 
to transmit the packet to the TCP/UDP processing unit 
23. 

The DNS packet separating unit 241 included 
in the expanded DNS client 24 receives the DNS packet 

20 from the TCP/UDP processing unit 23, check the content 
of the DNS header, and then separate it into the domain 
name resolver 242 or the public key inquiry processing 
unit 243. Like the conventional DNS client, the domain 
name resolver 242 performs a process of solving the IP 

25 address for the domain name. When inquiring the IP 
address for the domain name, the domain name resolver 
242 operates to transmit the packet of inquiry through 
the TCP/UDP processing unit 23. The domain name solver 
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242 operates to receive the answer for the inquiry 
through the TCP/UDP processing unit 23. 

The public key inquiry processing unit 243, 
which is a newly added module in this invention, 
5 performs a process of solving the public key for the 
domain name. The public key inquiry processing unit 

243 operates to store the newly obtained information on 
the public key in the domain name/public key/electronic 
signature table 25, to which it refers before inquiring 

10 the public key for the next time. The electronic 
signature check unit 244 operates to refer to the 
domain name/public key 2 63 of the trusted KMS of the 
initial holding data 2 6 about the information on the 
public key received by the public key inquiry 

15 processing unit 243 and then determine if the 

electronic signature added to the information on the 
public key is obtained by the trusted KMS and check if 
the information on the public key may be trusted. 

The public key inquiry processing unit 243 

2 0 operates to select the most approximate trusted KMS of 
the domain name/public key 263 of the trusted KMS 
according to the domain name for inquiring the public 
key. The host 2 0 includes its own domain name/public 
key 261 and the domain name 2 62 of the upper KMS in the 

2 5 initial holding data 26. The public key inquiry 

processing unit 243 operates to refer to its own domain 
name/public key 261 and the domain name 262 of the 
upper KMS. The security communication processing unit 
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27 operates to do security communication based on the 
public key of the target host obtained by the public 
key inquiry processing unit 243 according to the 
conventional method. 
5 In turn, the description will be oriented to 

the routine in which the host obtains the public key of 
the target host in the network shown in Fig. 7 in the 
case of applying the present invention to the network 
having a hierarchical domain name structure with 
10 reference to the flowchart shown in Fig. 4 and Fig. 8 
for indicating the types of the packets to be 
transferred between the host and the KMS and between 
the KMS and the KMS and the electronic signatures to be 
added to the packets. 

In Fig. 7, KMSO (73), KMSl (72), KMS2 (76), 
and KMSOO (S74 ) are the KMS having the structure 
described witK reference to Fig. 1. The hosts A71 and 
B75 are the hos"t!s having a function of the expanded DNS 
client having the c^figuration shown in Fig- 2. Then, 
20 the KMSOO (74) is connected to the network 701 having a 
domain name xx. The KMS0\/73) is connected to the 
network 7 02 having a domain name a.xx. The hosts A71 
and KMSl (72) are connected to network 73 having a 

domain name b.a.xx. The host B7 5 ahd the KMS2 (76) are 
25 connected to the network 704 having a o^main name 
c . a . XX . 

The domain name has a hierarchical "^ructure, 
in which each KMS is served as the conventional BlNS 





- 22 - 

sei^v^. Fig. 8 shows the operation of each KMS if only 
the KMS2">3^) has the information on the public key of 
the host B75. E^aQh arrow shown in Fig. 8 shows the 
packets to be transferred between the host and the KMS 
5 and between the KMS and theKt^ and the format of the 
electronic signature to be added trci the packet when the 
host A71 obtains the public key of the B75. The 

types of the packets include a public key inqttixy, an 
electronic signature request, and a public key ans^^i^. 
10 As represented by the symbols in the square of Fig. 8, 
the concrete content of the electronic signature is 
defined as follows. 

S(K/ [a, b, c]) : Electronic signature given 
to message [a, b, c] by a key K 
15 D{X): Domain name of X 

S(X): Public key of X 
T(X): Secret key of X 
IP(X): IP address of X 

KMS(X): KMS whose electronic signature is 
2 0 requested by X 

Later, the flow of Fig. 4 will be described 
on the as^&umption that the KMS whose electronic 
signature is reqta^sted by the host A71 is KMSOO (74). 

(1) At first>v^he host A operates to transmit 
25 the packet for inquiring the'^^public key of the host B75 
to the KMSl (72). As indicated b^x^ arrow 81 in Fig. 
8, the packet for inquiring this publicS^ey is as 
follows . 
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S(T(A), [D(B), KMS(A), IP(A), D(A)]) 
As will understood from the foregoing definition, 
the electronic signature is given by the secret key of 
the host A to\the message made up of the domain name of 
5 the host B, the i^S whose electronic signature is 

requested by the host A, the IP address of the host A, 
and the domain name of the host A. When the KMSl (72) 
receives the packet f orNinquiring the public key of the 
host B75 from the host A7]\ the electronic signature 
10 processing unit 144 shown in^ig, 1 operates to check 
the electronic signature added \o the packet. The 
electronic signature processing unsit 144 operates to 
pick up the public key of the host AS(1 from the domain 
name/public key /electronic signature table 16 and 
15 determine if the content of the packet is\interpolated 
through the use of the public key (step 41 )> 

(2) If the inquiring packet is interpolated 
in the determination at the step 41, the KMSl (72) 
abandons the packet and then terminates the process. 
20 Unless the inquiring packet is interpolated, the public 
key inquiry/answer processing unit 143 shown in Fig. 1 
is operated to check if an entry is given in the domain 
name/public key/electronic signature table 16 about the 
domain name of inquiry. Herein, if it is determined 
25 that more than a certain time is passed by referring to 
the time stamp, it is assumed as an effective entry 
(steps 43 and 42) 
^ \^ (3) lTTro"''efttey--is^ found in the domain 
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n^e/public key /electronic signature table 16 in the 
dete^nnination at the step 42, the public key 
inquiry^answer processing unit 143 of the KMSl (72) 
shown in fvig. 7 determines if the domain name of the 
host of inquiry is matched to the name of the network 
to which the host belongs and the domain name of the 
KMSl (72) is matc^ied to the name of the network to 
which the KMSl ( 72 ) ^belongs • For example, in Fig. 7, 
if the host of inquiry\is B75, the domain name c.a.xx 
of the network to which BJ5 belongs does not coincide 
with the domain name b,a.xx\of the network to which 
KMSl (72) belongs (step 44) 

(4) If the names of the network coincide with 
each other in the determination at the step 44, the 
KMSl (72) shown in Fig. 7 notifies the host A71 of the 
fact that the public key to the host B is unsolved 
( step 45 ) . 

(5) If the names of the networks do not 
coincide wrt;h each other in the determination at the 

0 step 44, the KMSl (72) operates to check the inquiring 
destination by retiring to the domain name 172 of the 
upper KMS held in theN^itial holding data 17 in Fig. 1 
and then inquire the KMSO >73) of the public key of the 
host B75. The inquiring packet;^ is, as shown by an 

5 arrow 82 in Fig. 8, as follows. 

S(T(KMS1), [D(B), KMS(A), I>s(KMSl ) , D(KMSl)]) 
The message is made up of the domain namexpf the host 
B75, the domain name of the KMS whose electrd^ic 
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sigitature is requested by the host A71, the IP address 
of the K^Ssl (72), and the domain name of the KMSl (72) 
with addition X3<f an electronic signature whose key is 
the secret key of tl>e KMSl (72). The addition of the 
5 electronic signature ser\^^ to prevent malignant 

interpolation of the inquirin^sj>scket by adding the 
electronic signature (step 46), 

(6) Then, The KMSl (72) determines if an 
inquirer of a public key to the KMSl (72) is a host or 

10 another KMS from a start-point IP address of the packet 
for inquiring the public key. If another KMS inquires 
the public key, the process is terminated (step 461). 

(7) If at the step 461 an inquirer of a 
public key to the KMSl (72) is a host, the public key 

15 inquiry/answer processing unit 143 waits for a certain 
interval of time until the answer to the public key 
comes from the upper KMS. If no answer to the public 
key comes within a certain interval of time and no 
public key with an electronic signature added thereto 

20 can be obtained, the process is terminated (steps 462, 
463 ). 

(8) If the answer to the public key with the 
electronic signature comes within a certain interval of 
time, the public key inquiry /answer processing unit 143 

2 5 operates to cache the public key in the domain 

name/public key /electronic signature table 16 shown in 
Fig. 1. By doing such caching, if another host 
inquires a public key about the same domain name, the 
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public key inquiry/answer processing unit 143 does not 
need to inquire another KMS of the public key again, 
which makes the process of solving the public key more 
efficient (step 464). 
5 (9) Next, the public key inquiry /answer 

processing unit 143, as shown by an arrow 87 in Fig. 8, 
gives back the public key answer packet with its own 
electronic signature to the host having received the 
inquiry of the public key. The public key answer 
10 packet with the electronic signature has as a message 
D(KMSl), D(B), S(B), S(T(KMSOO)), [D(B), S(B), 
D{KMSOO)] and as a signature key a secret key T(KMSl) 
(step 465 ) . 

(10) If an entry is found in the domain 

15 name/public key/electronic signature table 16 in the 
search for the database at the step 42, the public key 
inquiry /answer processing unit 143 shown in Fig. 1 
operates to check if the entry has an electronic 
signature of the specified KMS (step 47). 

(11) If an entry is added to the electronic 
signature ofs^he specified KMS in the check at the step 
47, the public key inquiry/answer processing unit 143 
gives the public keyN(jn.th the electronic signature in 
the entry back to the hosXA71 (step 48). 

25 (12) On the other h^^, if the entry has no 

electronic signature of the specifl^^ KMS at the step 
47, the public key inquiry /answer processing unit 143 
operates to check the KMS trusted by the hos^A 71 and 
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a5<ed to the packet and the domain name 172 of the 
upperN^S of the initial holding data shown in Fig. 1. 
Then, the imit 143 operates to issue a request for an 
electronic signature to the KMSO (73) shown in Fig. 7. 
5 If the KMS2 (76) n^s information on the public key of 
the host B75 and issuers, a request for an electronic 
signature to the KMSO (73)Vas shown by an arrow 84 in 
Fig. 8, with [D(B), KMS(A), I^^^MSl), S(B) and D(KMS2)] 
as a message, the request with thes^lectronic signature 
10 whose key is a secret key of KMS2 (76)\4-s given (step 
49) . 

As stated before, the description has 
concerned with the operation of KMSl (72) in Fig. 7. 
The other KMSO (73) and KMS2 (76) are operated in the 
15 similar manner to the KMSl (72). 

In turn, the description will be oriented to 
the request and the answer for the electronic signature 
in the operation of each unit of the KMS shown in Fig. 
1 with reference to the flow of Fig. 5 and Figs. 7 and 
20 8. 

(1) Now, it is assumed that the KMSO (73) 
shown in Fig. 7 has received the request for an 
electronic signature from the KMSl (72). In this case, 
the KMSO (73) operates the electronic signature 
25 processing unit 144 within the device having the 

configuration shown in Fig. 1 and then checks for the 
electronic signature added to the packet. The 
electronic signature processing unit 144 operates to 
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pick up the public key of the KMS 172 form the domain 
name/public key/electronic signature table 16 and 
determine if the content of the packet is interpolated 
(step 51 ) . 

5 (2) In the determination at the step 51, if 

the content of the packet is interpolated, the 
electronic signature processing unit 144 operates to 
abandon the packet and then the KMSO (73) terminates 
the process (step 53). 
10 (3) In the determination at the step 51, if 

the content of the packet is not interpolated, the 
electronic signature processing unit 144 operates to 
determine if the request for the electronic signature 
is directed for the KMSO (73) itself by checking the 
15 content of the packet (step 52). 

\ (4) In the determination at the step 52, if 
the requebst for the electronic signature is not 
directed for^t^e KMSO (73), the electronic signature 
processing unit r4^ operates to refer to the domain 
20 name 172 of the uppers^MS in the initial holding data 
and then issue the reques^ f or an electronic signature 
to the upper KMS. In Fig. 7/\if the KMS whose 
electronic signature is requesteH^by the host A71 is 
KMSOO (74), as shown by an arrow 85N^i Fig. 8, the 
25 packet for requesting an electronic sign^ure given 

from the KMSO (73) to the KMSOO (74) has an^ectronic 
signature whose key is the secret key of the KM^^(73) 
with [D(B), KMS(A), IP(KMSl), S(B) and D(KMSO)] asVv 
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message 

(5) On the other hand, in the determination 
at the step 52, if the request for the electronic 
signature is directed for the KMSO (73) itself, the 
5 electronic signature processing unit 144 operates to 
add the electronic signature to the requested packet by 
using its own secret key and give back the packet with 
the electronic signature to the requester KMS . In the 
example being described now, for example, as shown by 
10 an arrow 86 of Fig. 8, the answer packet includes an 

electronic signature added thereto with [D(B), S(B) and 
D(KMSOO)] as a message and the secret key of KMSOO (74) 
as a key (step 55). 

In turn, the description will be oriented to 
15 the operation of the host having the configuration 
shown in Fig. 2 with reference to the flow of Fig. 6 
and Figs. 7 and 8. 

(1) In Fig. 7, it is assumed that the host 
A71 tries tbsacquire the open key of the host B75. At 
20 this time, the open key inquiry processing unit 243 of 
the host A71 having^t^e configuration shown in Fig. 2 
operates to retrieve theNJomain name/public 
key/electronic signature tabl>e 25 for checking if any 
entry to the host B7 5 is given (s<t^p 61). 
25 (2) At the step 61, if no^ntry to the host 

B75 is found in the domain name/public kfey/electronic 
signature table 25, the public key inquiry plis^ocessing 
unit 243 operates to refer to the domain name/piJkaic 
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cey 263 of the trusted KMS in the initial holding data 
2ei for selecting the trusted KMS. If two or more 
doimin name/public keys 263 of the trusted KMS are 
founci, the unit 243 operates to select the KMS that is 
upper Vhan and closest to the domain name of inquiry 
( step 62^) . 

(3) Next, the public key inquiry processing 
unit 243 operates to refer to the domain name 262 of 
the KMS for Vnquiring the public key in the initial 
10 holding data 26, for inquiring the KMS of the host B75. 
The packet for Vnquiring the public key includes an 
electronic signature with [D(B), KMS(A), IP(A) and 
D(A)] as a message\and the secret key T(A) of the host 
A as a key (step 63) 
15 (4) When theXpublic key answer packet is 

given back in response tc) the inquiry at the step 63, 
the host A71 operates the electronic signature check 
unit 244 shown in Fig. 2 and^then checks if the 
electronic signature added to \he public key answer 
20 packet is given by the requestedyKMS and the content of 
the packet is interpolated (step 6n^ ) . 

(5) If the public key answer packet is not 
given back within a certain interval osE time or it is 
checked that at the step 64 the electromLc signature 
25 added to the public key answer packet is gsiven by the 
requested KMS and the content of the packetNis 
interpolated, the host A71 terminates the process 
without taking any action. This makes it possible to 
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prevervfcN^ malignant host from being feigned to be a 
target host of the security communication by pretending 
its own public ke^^^^d address to correspond with the 
inquired domain name . ^^v^^ 

5 (6) If at the step 64 it is determined that 

the electronic signature added to the public key answer 
packet, is given by the requested KMS and the content of 
the packet is not interpolated, the public key inquiry 
processing unit 243 operates to check the content of 

0 the public key answer packet and cache a combination of 
a domain name, a public key, an electronic signature, 
and a domain name of the KMS with the signature added 
thereto in the domain name/public key/electronic 
signature table 25 (step 65). 

5 ^"^^---^ ) The security communication processing 

unit 276 of the^^-hQst A71 operates to start the process 
for the security communic'&^fe^on through the use of the 
public key acquired by the f oregoifrg-..erocess or the 
public key found at the step 61 (step 66).^"""-^^^--.-^ 

0 The implementation of the foregoing process 

by the host makes the process for solving the public 
key more efficient. 

According to the foregoing embodiment of the 
invention, two hosts in the network enables to 

5 automatically acquire the corresponding public key to 
the domain name of the target host through the use of 
the function-expanded DNS server before starting the 
security communication. This makes it easier to manage 
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the public key- 

According to the foregoing embodiment of the 
invention, the DNS server specified by the host is 
served to add the electronic signature to the public 
5 key answer packet. This makes it possible to prevent a 
malignant host from being feigned to be the target host 
of the security communication by pretending the public 
key and the address of the malignant host to correspond 
with the domain name of inquiry, 

10 As set forth above, according to the 

invention, the program for realizing the present 
invention is stored in the storage medium such as a FD 
or CD-ROM and then the program is installed in the DNS 
server and the host. Further, the present invention is 

15 configured to store the program for realizing the 
invention in the storage medium located in the 
information processing apparatus connected to the 
network and copy the program in the storage medium such 
as a harddisk located in the DNS server and the host 

20 through the network, for realizing the invention in the 
DNS server and the host. 



